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1 Introduction 

This document addresses the functional requirements spelled out in Contract [1] Section 

6.111- 6 and its subsections, as well as applicable requirements from Contract [1] Section 

6.111- 3. 

The hardware design elements are addressed in SEA-01047, as referenced in Section 2 
Hardware Design. 

The functionality design detail is contained in Section 3 and any subsections. 

Section 4 on Quality Assurance is applicable equally to the hardware and functionality 
design sections. 


1.1 Purpose 

This specification establishes the performance, design, development, and test 
specifications for the Driver Display Unit (DDU) at a Final Design Review (FDR) level. 


1.2 Scope 

The scope of this document is limited to the FDR-level functionality design of the DDU. 

Note: The DDU provides the driver display and keypad input for the control 
aspect of the On-Board Fare Transaction Processor (OBFTP) as well as 
third-party devices and applications. In the case of the OBFTP, fare 
collection functionality is provided in the following document: SEA-01050 
Fare Transaction Processor - Functional Specification (DR 102B) [7]. 


1.3 

1.3.1 


Terminology 

This section contains a list of acronyms, abbreviations, and terms used in this document. 


Acronyms and Abbreviations 


Table 1 contains the acronyms and abbreviations that are specific to ERG. Industry 
standard acronyms and abbreviations are not defined in this table. 


Table 1: Acronyms and Abbreviations 


Acronym or 
Abbreviation 


AFC 


API 


CD 


CSC 


CT 


Definition 


Automated Fare Collection 
Application Programmers Interface 
Configuration Data 
Contactless Smart Card 
Community Transit 
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keypad 

operatoi 


List of stolen or otherwise invalid devices that should not be used in the 
system. If a device detects that a fare card has had a revalue applied by 
one of these hotlisted devices, then the device may take some action, 
e.g., blocking the card, according to the system business rules. Device 
authentication nodes, e.g., DAC, may also use this list to prevent stolen 
device access to the system. 

Synonymous with keyboard. 


The Agency staff member, ESB staff member, or any authorized person 
using the RFCS equipment. 


1.4 
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2 Hardware Design (refer to SEA-01047 Driver 

Display Unit -- Hardware Specification 
(DR 103 A)) 

This section is intentionally left blank. 
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3 Functionality Design 


3.1 Introduction 

The DDU software and even the hardware have been designed to allow the Agencies 
flexibility in the future to make use of DDUs provided by third parties, with minimal 
changes to the software in the system. 

The DDU software architecture has been designed to have fare collection functionality in 
the OBFTP, leaving the DDU to provide operators with display and audio feedback and a 
keypad to control the OBFTP and other third-party equipment. 

The DDU supports multiple applications, including applications by others. As such, the 
DDU application architecture incorporates a number of executive applications to manage 
the interaction of different applications and to provide a mechanism for all applications to 
share the DDU display and keypad resources. The executive applications are the 
Application Manager, Template Manager, Status and Logging Application, AFC 
Application, Management Application, Monitor Application, and the Watchdog 
Application. For more details see section 3.9.1. 

Configurable display software templates have been employed to allow Agencies to 
customize the layout of messages from different applications (including OBFTP 
messages) on different screens. Additionally, the templates allow Agencies to customize 
the allocation of hotkey functions on all templates to suit applications used by each 
Agency and in arrangements that suit the operators' and Agencies' operations and 
policies. 

The fare collection functionality is defined in SEA-01050 Fare Transaction Processor - 
Functional Specification (DR 102B) [10]. The DDU as described in this document 
describes the interface between the OBFTP and the DDU and the mechanisms by which 
the OBFTP makes use of the DDU display, audio, and keypad resources to fulfill this 
functionality. 


3.2 Operational Architecture 


SEA-01048 
Revision 16.0 122 


The DDU is designed to provide an interface to the OBFTP, the VLU and other on-board 
systems. The DDU is interoperable with a minimum of six additional on-board systems or 
applications, including the RCU and the VLU. 

Although Windows CE.net is not a real-time operating system, the DDU executive 
application arbitrates needs of all third-party applications so that events from all 
applications are processed in a timely manner. The template manager, along with 
guidelines for third-party applications to be designed to work within the DDU template 
framework, further enables the DDU executive to achieve this result. 


Figures (3 and 4) in SEA-01047 Driver Display Unit (DR 103A) - Hardware Specification; 
[6]) depict the LIM and FIM architectures, respectively, of the on-board system with which 
the DDU interfaces. In both architectures, the DDU automatically serves as the operator 
input, control, visual display, and audible alert device. In operation, the DDU interfaces 
with the OBFTP for fare collection and mimics the OBFTP patron display on its own 
operator display. 


In the event of a failure of the OBFTP, the DDU remains operational as 
interface to all other on-board systems. 


operator 
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3.3 Device Role 

The DDU provides the following major functionality: 

• A operator interface to provide keyboard (DR 103.01) input, an LCD (DR 103.02) 
display, and an audio interface for operator feedback 

• A communications interface to the OBFTP and other on-board RFCS and third-party 
devices for transaction messaging and device control 

• Automatic integration into LIM and FIM on-board systems 

The DDU provides the human interface to all RFCS on-board systems in mobile 
environments. The DDU provides an LCD display and audio feedback to the operator. 
The DDU interfaces with all on-board systems, including the OBFTP, for the processing 
of contactless smart card (CSC) fare card transactions and for the display of transaction 
information, feedback, and status. 

Operator logon and logoff to the OBFTP and other on-board systems occur either on 
presentation of an operator card and entry of an associated password using the keyboard 
or by manual logon with an operator ID and password. Prompts and feedback are 
provided by the DDU LCD and audio interfaces during the logon process. Operator logon 
and logoff operations are logged as usage data (UD) for audit purposes and are made 
available for transfer over the WDOLS. Where required, OBFTP logon information and 
data is shared with other on-board devices to provide for a single point of logon or logoff 
to the entire on-board system. 

The DDU keyboard can be used by the operator to control the OBFTP for specific fare 
collection functions, or to interact with other third-party equipment or applications. Each 
keyboard key is programmable as a hotkey and can be assigned a context-sensitive 
function, thus minimizing the number of keystrokes required for navigation of menus and 
system options. Key functions are dynamically assigned when different screens are 
presented. This capability addresses the requirements defined in Contract [1] Section 
6.111-6.2.1 (f) and (k). 

Note: The DDU does not allow fare card transaction data to be collected unless 
the Agency specified log-on method has been completed successfully. The 
functionality of third-party applications running on the DDU in the event of 
incorrect logon data will be up to each application. Refer to SEA-01100 
ERGRFI 00213 (1-000385) - Collect data with incorrect logon [31]. 
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3.4 External Interfaces 


Figure 1 Illustrates the DDU external software interfaces. 



Figure 1: DDU External Software Interfaces 

The DDU communicates with the following external devices: 

• OBFTP (through Ethernet) 

• Diagnostic PC (through RS232) 

• Third-party devices (VLU, RCU (through J1708), CT devices (through RS485)) 

Note: The ignition input to the DDU has both hardware and software 
components, where the software component refers to control by the 
executive application, for example, delaying power down during data 
transfers to the DAC or a timeout occurring. 


3.5 Operating System and Base Functionality 


3.5.1 Operating System 

The DDU uses a commercially available third-party processor board running the 
Windows CE.net operating system. Refer to SEA-01047 Driver Display Unit (DR 103A) - 
Hardware Specification [6] for additional details of the DDU processor hardware. 


3.5.2 File Systems 

The operating system provides a Windows FAT Filing System for the persistent storage 
of the DDU application, boot-loader, and other pertinent data in flash memory. SDRAM is 
used for program execution and volatile storage. 
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3.5.3 Software Installation 


For the DDU software architecture there are two fundamental components: 

1. Executive infrastructure (see section 3.9.1), namely: 
a Application Manager 

b Template Manager 
c Status and Logging 
d AFC Application 
e Management Application 
f Watchdog Application 
g Monitor Application 

2. Applications, covering both ERG and third-party applications that provide operational 
functionality and/or management over other on-bus equipment. 

There are a number of considerations for software installation, as follows: 


Windows CE.net Operating System 

The operating system is supplied with the third-party processor hardware used in the 
DDU. The third-party operating system is not part of the system configuration data from 
the Central System, and needs to be installed if necessary as a maintenance function. 

The same is true for a DDU by others. That is, any operating system files to be installed 
on the device are not part of system CD and must be installed by an alternate 
mechanism. 

Details of the Windows CE.net operating system are available at the Windows web site 
www.windows.com (more specifically using the MSDN library reference at 
http://msdn.microsoft.com/librarv/default.asp7urlMibrarv/en- 

us/wcemain4/html/cmconkernel.asp ). 

Sections 3.5.3.1.1 and 3.5.3.1.2 are extracts from the MSDN library reference. 


The kernel, which is represented by the Nk.exe module, is the core of the Microsoft 
Windows CE operating system (OS). The kernel provides the base OS functionality for 
any Windows CE-based device. This functionality includes process, thread, and memory 
management. The kernel also provides some file management functionality. The kernel 
services enable applications to use this core functionality. 

3.5.3.1.2 TCP/IP Stack 

The Microsoft Windows CE OS includes a standards-based TCP/IP stack, allowing 
Windows CE-based devices to participate as peers and servers on local area networks 
(LANs) and remote networks. 
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The TCP/IP suite for Windows CE was designed to ease integration of Microsoft systems 
into the embedded market, telecommunications, the enterprise, the consumer market, 
government, and public networks. It also provides the ability to operate over those 
networks in a secure manner. Windows CE is an Internet-ready operating system. 
Windows CE supports the following standard features: 

• The ability to bind to multiple network adapters with different media types, for 
example, 802.3 and 802.5. 

• Logical and physical multihoming capabilities. 

• Internal IP routing capability. 

• Internet Group Management Protocol (IGMP) Version 3 (IP Multicasting). 

• Duplicate IP address detection. 

• Multiple default gateways. 

• Dead gateway detection. 

• Automatic Path Maximum Transmission Unit (PMTU) discovery. 

• Virtual Private Networks (VPNs). 

Windows CE provides the following services: 

• Dynamic Host Configuration Protocol (DHCP) client. 

• Windows Internet Name Service (WINS), a NetBIOS name client. 

• Domain Name System (DNS) client. 

• Dial-up (PPP/SLIP) support. 

• TCP/IP network printing. No built-in support for Ipr or Ipd is provided. However, 
independent software vendors (ISVs) and original equipment manufacturers (OEMs) 
could add support for Ipr/lpd to Windows CE. 

• SNMP extension agent, providing a MIB-2 subagent that allows the state of TCP/IP to 
be monitored and controlled. 

• Windows Sockets (Winsock) Version 2.2 interface 

• Wide Area Network (WAN) support 

• Basic TCP/IP connectivity utilities, including FTP and telnet servers. 


The DDU executive covers executive and support applications and data files. These 
applications are listed and explained in section 3.9.1 and subsections. 

These executive components are part of the system CD, and they are downloaded from 
the DAC directly to the DDU as part of CD payloads for the DDU. Part of this CD is a 
manifest detailing what DDU applications and data files are required to be downloaded, 
and what versions these should be. 

Note: As per SEA-01193 ERG RFI (1-000404) - Operation of DDU without 
OBFTP [32] The DDU receives configuration data directly from the DAC, 
using the same secure transport mechanism as deployed on the OBFTP 
and other RFCS equipment. This functionality enables the DDU to operate 
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independently of the OBFTP, while providing a secure connection to the 
DAC for application and data updates. 


DDU Applications 

These are applications/files by ERG and third parties that are required to run on the DDU. 
These applications are certified by ERG to run concurrently with any existing DDU 
applications, using the application framework and management described throughout this 
document. 

These applications are downloaded to the DDU using the same secure transfer 
mechanism as described above for the DDU executive. 

The system CD downloaded to the DDU includes a manifest of files required by the DDU 
and the applicable version of each file. This manifest also includes details of applications 
that have been certified by ERG to run on the DDU. The CD transfer mechanism on the 
DDU ensures that only certified applications (of the correct version) are downloaded. The 
DDU Executive will install the applicable applications during start-up. 


3.6 Application Certification 

As described in section 3.5.3, third-party applications are required to be certified by ERG 
prior to being downloaded to and run on the DDU. Only applications that have been 
certified can be included in DDU configuration data and loaded or run on the DDU. 

There are two components of third-party design that require certification, namely: 

• Applications for third-party devices 

These are the applications to be run on the DDU. As described in section 3.5.3, these 
applications are downloaded using the CD distribution process. 

• Templates designed or modified by Agencies 

These are DDU templates (see sections 3.8.4, and 3.9.3) that can be customized for 
each Agency and provide the mechanism to control DDU display arrangements and 
the assignment of hotkey functionality. The templates form part of the system CD and 
are downloaded to the DDU. 

The following subsections detail requirements for third-party application development, 
and processes involved in application certification. 


3.6.1 Development Kit 

A development kit for third-party developers will be prepared to assist in standardization 

and compliance. This kit will contain: 

• Specifications for the Windows CE.net run-time environment and Windows CE.net 
version information applicable to the DDU that can assist the developer 

• Application guidelines as per section 3.6.2 

• Other relevant DDU documentation, e.g. details related to the Template Manager as 
described in section 3.9.3 

• Standard library and DLL files required to implement template handling, INI file 
handling, and any other DDU standard functionality (to be defined). 
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A standard template file that can be used by the developer. This file will be extensively 
documented by comments and have additional notes to assist the developer. 

A compliance form to be completed by the developer and submitted as part of the 
certification process 


3.6.2 Application Guidelines 

Any third-party applications to be written for the DDU must adhere to the framework 

provided by the DDU application architecture as outlined in section 3.9.1. That is, the 

applications must be written to: 

• Use facilities provided by the Template Manager to obtain access to the display, 
keypad, and audio resources of the DDU. This ensures that all resources can be 
shared by all applications, taking into consideration the provision for assignment of 
priorities to applications. 

• Use facilities provided by the Status and Logging application to provide particular 
status and event information to the operator. This enables existing templates 
employing the Status and Logging application to be used unchanged, even when new 
third-party applications are added in the future. 

• Use watchdog counter facilities provided by the Watchdog application to catch and act 
upon applications that misbehave in certain ways. 

• Optionally use the menu/command registration facilities of the Monitor application to 
provide diagnostic capabilities. 

• Make use of the data generated by the AFC application as applicable. 


3.6.3 Template Guidelines 

When any new templates are defined or existing templates are modified, they must also 
be certified, even if there are no new applications. 

An application front end will be provided to generate the DDU template file. This will 
enforce a number of restrictions, such as preserving particular fare collection templates 
and defining global hotkey definitions. This application also ensures that any DDU 
template file will be complete and be parsed correctly by the Template Manager. 

Although the arrangement of application windows and hotkey assignments is 
configurable by each Agency, care is required to ensure that access to application data is 
not lost by resizing of application windows or that functionality is not lost by reassignment 
of hotkeys. 

Note: ERG recommends the reservation of two of the 12 hotkeys located on the 
DDU sides for navigational purposes (per the Contract [1], Section 6.III- 
6.2.1(f) and (k)). These two keys would provide the functionality to return 
to the top-level screen and previous screen respectively. This is subject to 
override and/or design approval and could be incorporated into the 
certification process. 

These two navigation buttons ensure that all screens are reachable, and 
allow quick movement between screens. Any proposed changes to these 
keys should take the complete screen-flow into consideration. 
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• Application windows are not resized smaller than requirements for that application. 
Exceptions to this rule apply when clipped windows are acceptable, or when 
applications are intelligent and can resize window content to suit window sizing. 

• If fewer than the total number of hotkeys required by an application are assigned on a 
template, then a hotkey should be assigned to allow switching to a different template 
that has the correct number of hotkeys required by the application. 

• Provision is provided on all templates to allow sensible and logical transition between 
templates. 

3.6.4 Certification Deliverables 

There are a number of deliverables required from third-party application developers in 
order for ERG to process an application certification request. These deliverables are 
outlined in the subsections that follow. 


J.6.4.1 


Compliance Form 

The compliance form lists a number of questions that reinforce the compliance guidelines 
from the application guidelines as described in section 3.6.2. In addition, it lists all 
application components and documentation supplied for compliance testing as well as 
additional notes required for application compilation, set up, and testing. 

The developer must supply the completed form when the application is submitted for 
compliance testing. The ERG staff responsible for compliance testing will scrutinize the 
compliance form, check it against the code and documents supplied, and sign it off 
before any compliance testing is started. 

If the compliance form is incomplete or any application components or documentation do 
not match the compliance form or are inadequate for compliance testing, the compliance 
test is halted until the developer corrects the situation and issues a new compliance form 
(and components). All copies of compliance forms are filed (including rejected ones). 


3.6.4.2 Application Documentation 

Any documentation supplied with the application will be scrutinized to ensure that it is 

adequate for understanding the application to be tested and to also form the basis of 

future client support required by ERG maintenance staff. 

Documentation should also include (in addition to that related to the application or 

template file) the following: 

• Application revision history. This is particularly important to indicate new applications 
from ones that are revisions, as this would affect how much process/testing, etc. the 
ERG staff would be required to do. The revision should indicate whether it is a “bug- 
fix” (minor version update) versus new functionality (major version update). The 
application version would also be included on the completed compliance form 
described in section 3.6.4.I. 

• Sample data file(s) for the updated application to use. 

• Test scenarios and expected results (screens, logs, etc.). 

• Required connected equipment (actual or simulated). 

• Communications logs (as applicable) to verify/allow the application to function. 
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J.6.4.3 


DDU Template File 

This is the template file used by developers in developing and testing their applications. 

This template file will be merged with the existing master template file prior to application 

certification and testing. 

Note: It is expected that one main constraint on a third party prior to beginning 
the development of a DDU application is knowledge of the applicable 
Agencies’ templates, particularly, what screen area is available for the 
new application window and what hotkeys are available for use by the 
application. 


3.6.4.4 DDU Application 

This is the application, including libraries, etc. The application should be supplied in 
source code, as well as the runtime executable and any libraries. 

Note: As source code is required, nondisclosure agreements may be required by 
Agencies or third-party developers to protect their intellectual property. 


3.6.5 Certification Process 

Certification involves verifying the following factors for any applications modified or new 

applications created: 

• Build documentation reflects that applications are built for a standard Windows CE.net 
environment and that the application is compatible with the hardware specifications of 
the DDU described in section 2. 

• Design documentation declares compliance with template guidelines for interfacing 
with DDU resources. 

• Code walk-through demonstrates correct interface with DDU resources. 

• The amount of device memory required or used is acceptable given requirements by 
other applications and available memory. DDU memory can be increased on an as 
needed basis subject to agreement between ERG and the Agencies. 

• The application does not use processor or resource locking calls that could prevent 
other applications from performing correctly. 

• The application loads correctly, can be launched by the application manager, and 
does not cause any other applications to become inoperable. 

• The application operates correctly with the other base DDU applications, such as the 
Watchdog application, the Status and Logging applications, and others listed in 
section 3.9.1. 

• All functions operate as required according to the functional specification of the 
application. A functional test specification that declares boundary tests and tests for all 
interfaces used by the application is required for each application. 

Processes specifically related to the template file or application are described in the 

following subsections. 
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3.6.5.1 


Certifying the Template File 

The template file must be visually inspected before merging with a copy of the existing 
DDU template file (Agency-specific) for compliance testing. The initial test should be to 
run the AFC application, using the newly merged template file, to ensure that the TDL 
parser does not find any coding or merging errors. 

Corrections should be made only if there are merging errors. 

Any merging or coding errors detected will be documented and reported back to the 
developer for correction and resubmission for certification. 

Note: Along with the introduction of a new application, the top-level DDU 
template will require modification to add a link to a new template required 
by the application. Additionally, changes to other existing templates may 
be required if the Agency requires new application functions or message 
displays to be incorporated into these templates or if the Agency requires 
links to the new application template to be added. 


Certifying the Application 

Application compliance requires that the source code also be supplied. This should be 
scrutinized prior to recompiling and testing. 

As complete testing of the application by ERG certification staff is probably not practical, 
testing will concentrate on making sure that the submitted application does not impact 
other applications running on the DDU and that it complies with all requirements stated in 
the application guidelines of section 3.6.2. 

Note: For the functional testing of the new application, the new application 
template is tested at the same time. That is, tests are performed to verify 
that all hotkey functions are accessible and operate correctly and that all 
message displays are correct. Additionally, where existing templates have 
been changed, tests are performed to verify that existing functions on 
these templates continue to operate as before; that is, all functionality is 
still accessible and operates correctly. 


Certification Code 

ERG will consider a method of generating a certification code that is supplied by ERG 
and compiled into the application together with a means of checking the code at start up 
by the DDU Applications Manager. 

This certification code will not be supplied to the developer and will be implemented in 
such a way that the application will not launch if the code is not present. This ensures 
that any rogue applications will not be executed. 


J.6.5.4 


Application Testing 

Third-party application developers will be able to do testing without a certification code. 
To allow this testing, special consideration is given to the development test environment 
as follows: 

• Applications and data will be loaded into the DDU manually (Windows file handling), 
and not via the normal CD download mechanism from the DAC. 
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• A test version of the template file is used that indicates that application certification 
code checking is disabled. 

After the application has been certified, the certification code will be applied to the 
application at the Central System. 

In the Agency test bed and the revenue system, the certified third-party application will be 
downloaded as CD, the DDU application manifest in CD will include the application name 
and version, and a production template with certification code checking enabled will be 
used. In this environment, only certified applications can be used. 


3.7 Device Management 


3.7.1 Security 

For most applications the DDU is a low-security device, because it only provides visual 
feedback through the display and operator commands and data input through the 
keyboard. This includes communications to the OBFTP. Flowever, the DDU is configured 
with a software security module for the purpose of secure transfer of configuration data 
from DAC to the DDU. 

Note: The DDU will hold configuration and access control details for the WDOLS 
and access control details to the DAC. The DDU will also maintain the 
current logon object to be available to DDU applications. 

3.7.2 CD Download 

The DDU downloads CD directly via the WDOLS. The DDU executive application checks 
CD for validity after a download before being made active. 

3.7.3 LAN Messaging (DR 103.04) 

The DDU transmits data to and receives data from attached devices as instructions or 
messages for processing over an Ethernet LAN. These devices include the OBFTP, VLU 
and WDOLS. 
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Power Control and Monitoring 

The DDU is powered up when the ignition power input is energized. The DDU powers 
down when the ignition power is de-energized and a CD-configurable timeout has 
elapsed. 

A power button on the DDU is software configurable to implement specific power 
up/down strategies. For example, if a manual override of the timeout is required, the 
power button can be used to provide this feature. This can include requiring the operator 
to press the power button for an extended time, for example, five seconds. 


Note: The power button cannot be configured for any purpose other than power 
management strategies. 

The power button will be disabled, as required for the RFCS project. 

Power strategies are applied at a firmware level and so are common to all agencies. 
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3.7.5 

3.7.6 

3.8 


3.8.1 

3.8.2 


SEA-01048 
Revision ' 


RCU Messaging 

The DDU transmits data to and receives data from the RCU over a J1708 interface. 

CT Integration 

The DDU transmits data to and receives data from the CT Integration devices over an 
RS485 interface. These devices include the Transit Signal Priority (TSP), Destination 
Sign, and GFI Farebox. 

User Interfaces 

Operators interact with the DDU by means of the user interfaces. Table 3 defines these 
interfaces. 


Table 3: DDU Operator Interfaces 


Interface 


Use 


Operator LCD 


Display operational information. 


Operator Hotkey Keyboard 


Operator Audio 


Display icons indicating hotkey functionality (Graphical Menu 
System). 

Operator control input indicated by associated icons on the 
operator LCD. All operator control input required to operate 
the device is input on this keyboard. 

Operator audio feedback. 


Date and Time Formatting 

The time shown on the DDU will be in the format HFI:MM:SS where HH specifies hours, 
MM specifies minutes, and SS specifies seconds. 

Flours are displayed in 12-hour format. A suffix of AM or PM as appropriate will be 
included. 

The DDU will show only the day, abbreviated to 3 characters, and not the date. 

An example of the time/date shown on the DDU is shown below: 

TUE 12:42:06 PM 

Note: The date and time format above is as agreed with Agencies as a result of 
RFCS RFI 236. It is reflected in the screen flow presentations in Table 4. 

Language Formatting 

All text shown on the DDU display will be in U.S. English. 
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3.8.3 Number Formatting 

The division between whole numbers and parts of whole numbers is designated in the 
form of a decimal point. For example, one and one-half is represented as 1.5. 

The division between each third power of 10 in whole numbers is designated in the form 
of a comma, For example, two thousand three hundred is represented as 2,300. 

The currency unit is dollars. The decimal currency unit is cents. 

Decimal currency values are always specified to two decimal places; for example, 
$20.50. 

Currency symbols are presented before the value. 


3.8.4 Template Management 

The operator interaction with the DDU is configured by templates. Templates are 
controlled by the Template Manager and provide a mechanism for each Agency to 
customize DDU screens and associated hotkeys to suit their needs and to support the 
third-party applications also running on the DDU. 

The Template Manager is defined in more detail in section 3.9.3. 


3.9 DDU Application 


3.9.1 Application Architecture 

Figure 2 shows the DDU application architecture. 
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The DDU runs the following applications: 
• Application Manager 


• Status and Logging 

• Monitor 

• Management 

• Watchdog 

• AFC Application 

• Applications for third-party devices 

All DDU applications and any associated configuration data are updated by means of a 
CD download from the DAC. 

The applications listed in this subsection are explained in more detail in the following 
subsections. 
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Note: Device events, including ridership detail, are described in a table titled 
Event Messages Generated by the OBFTP in SEA-01050 Fare Transaction 
Processor (DR 102B) - Functional Specification [7], 

3.9.2 Application Manager 

The application manager is responsible for the following: 

• Startup of all applications controlled by a manifest of certified applications. The 
application manager uses certification codes to ensure that only certified applications 
are executed (refer to section 3.6.5.3). 

• Maintenance of an up-to-date and consistent set of third-party applications (including 
supporting DLLs and data files) by periodically downloading and checking an 
application manifest from the DAC whenever the WDOLS is in contact with the DAC. 
When the manifest indicates that new versions of third-party applications are 
available, the application manager retrieves those via CD from the DAC. Modules will 
become eligible to be started only when all modules specified in the manifest have 
been successfully loaded. 

3.9.3 Template Manager (DR 103.04) 

The Template Manager is responsible for the following: 

• At startup, to parse a template definition file and create associated data structures and 
other resources such as template windows 

• Control orderly access to the DDU's Ul elements by client applications 

As part of ensuring orderly access to client application functions, the DDU will ensure that 
the AFC application is not compromised by template changes by the operator part way 
through an AFC function sequence. 

Figure 3 shows an example of this situation, presenting a sequence of example DDU 
screen shots, highlighting the operator actions and screen changes. (Note that the 
application window detail and hotkey assignments are for illustration only.) 

In the example in Figure 3, an operator presses the ‘Home’ hotkey part way through a 
‘Change Fareset’ sequence, but the ‘Home’ template does not contain the AFC hotkey 
definitions to complete the sequence. If the operator presses an AFC hotkey (in the 
example, the ‘Next Trip’ hotkey) that is not accepted in the current AFC state (here, the 
Change Fareset state), the OBFTP will cancel the ‘Change Fareset' sequence and force 
an AFC state change and return to the On Trip state. The DDU template will not change, 
so that the new AFC hotkey (here, ‘Next Trip') is still available. This restriction is in place 
to ensure that operators can always recover from an interrupted AFC sequence and 
perform a new AFC function. 
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Figure 3: Template Sequence Recovery 


Change Fareset sequence 
cancelled and AFC state 
returns to On Trip state. 
Home template still 
displayed, and Next Trip 
hotkey still available. 


The Template Manager controls orderly access to the Ul elements by client applications. 
The Template Manager is controlled by a text file, which defines an arbitrary number of 
named screen templates using a template definition language (TDL). Each screen 
template provides a template frame with a title, a number of named client rectangles or 
windows. The file may also define a number of button layouts (called decals) that may be 
attached to any of the windows at run-time. 


On startup, client applications request handles to the windows provided by the templates. 
The windows are identified by a unique name. Windows may belong to multiple 
templates. When templates are activated, client windows are reassigned if needed. 
Clients should confine themselves to the windows obtained during startup. Note that 
Template Manager does not prevent client applications from creating their own top-level 
windows, but clients should only do this in exceptional circumstances. 
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A typical template might look like the example below: 



This template shows the 16 hotkey windows on the left, bottom and right side of the 
screen. The hotkey layouts (decals) define the source of these images and any actions to 
be taken when the adjacent physical DDU key is pushed. The Template Manager obtains 
the handles for the hotkey windows and draws the defined image into the client area. 
When a hotkey is pressed, the list of actions defined for that hotkey is executed 
sequentially. Actions include the ability to switch template or window or both. These may 
be specified either directly or by reference to a history buffer. In the latter case, the 
window that had the focus prior to the current one is switched to. Up to the last 10 
previous windows may be recalled. A window that resided on a template different from 
the current one will first invoke a change to that template. A hotkey definition may also 
specify a number of messages to be sent as part of its action list. Messages may be 
directed to a particular application window or to the active window. 

The sample template also shows 3 additional windows, which may be associated with up 
to 3 different applications. An application obtains a handle to the windows from the 
Template Manager and then creates a child window specifying the Template Manager 
supplied handle as the parent window. This ensures that the application is free to draw 
into the client area and prevents any application from drawing outside of its own window 
rectangles. 
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Note that templates may be changed without the need to rebuild client applications. For 
each window they control, the client applications will, in response to a WM_PAINT 
message, dynamically obtain the available drawing rectangle and utilize the available 
space appropriately. 

Permission to play an audio sequence is associated with template windows. Applications 
in control of a template window may unconditionally call a Template Manager function to 
play an audio sequence, but the template permissions determine if the audio is played. If 
multiple windows within a template have permission to play audio, then it is up to the 
applications to coordinate access to the audio resource. If a request to play an audio 
sequence is received by the Template Manager while another sequence is already 
playing, then the second request is discarded unless the second request is to turn the 
currently playing audio sequence off. 


All templates are defined in a template file written using TDL. An application will be 
provided as a front end to allow users to generate DDU templates. Detail of the template 
language is provided in Appendix B and provided in an overview here. 
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The template file contains the following: 

• Top-level template assignment 

• Template definitions. Constituent objects are: 

o Template name 
o Template text 

o Template windows. Constituent objects are: 

■ Window position 

■ Window size 

■ Audio associations 

• Decal definitions. Constituent objects are: 

o Decal name 

o Button definitions. Constituent objects are: 

■ Button position 

■ Image 

■ List of actions including messages and/or template switch 

Applications running on the DDU are associated with DDU resources (screen, keys, and 
audio) through the template definitions. Applications transmit information to and receive 
information from the DDU through a template window. 

Resources in each template can be associated with any number of applications. 


5.9.3.1 Top-Level Template Assignment 

The top-level template is assigned in the template file. It is the first template in the file. 
This defines the first template displayed after Template Manager is initialized. 

5.9.3.2 Template Definitions 

Any number of template definitions can be defined in the template file. Each template 
definition consists of: 

• Template name. This uniquely identifies each template definition in the template file. 

• Template text. This defines the top-level window name when the template is active. 

• Template windows. Note that windows do not have a title bar. 

The template definitions must contain at least one specific AFC template. This template 
must conform to the following constraints: 

• The AFC application main window size must be 240 x 128 pixels and visible. 

Note: The AFC application is the application running on the DDU that 
communicates with the fare collection application running on the OBFTP. 


Template Windows 

Any number of template windows can be defined in each template definition. Each 
template window defines the DDU resources assigned to that window in the template. 

The DDU resources assigned are: 
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• Position: the top left comer of the window, relative to the top left corner of the display 

• Size: the size of the window, defined in pixels in the x (horizontal) and y (vertical) 
directions 

• Resources: access to the speaker located in the DDU 


3.9.3.3 


Decal Definitions 

Any number of decal definitions can be defined in the template file. Each decal definition 
consists of: 

• Decal name. This uniquely identifies each decal definition in the template file. 

• Button/Hotkey definitions. Information describing each hotkey in the decal. 


Button/Hotkey Definitions 

Each decal definition can contain up to 16 button definitions. Each button definition 

defines the DDU resources assigned to that button/hotkey. 

The DDU resources assigned are: 

• Position: 0 (top left corner) to 15 (top right corner). 

• Image: The bitmap image to be displayed for the button. This can be specified as 
either a path to a bitmap file or as an index into an images file, which can be 
downloaded in CD. The support of path based bitmaps is for development and test 
purposes and is not intended to be used after development and testing is completed. 

• Action list: A list of actions to be taken by Template Manager when the hotkey is 
pressed. Can include the sending of one or more messages to a template window and 
a switch to a different template/window pair. 


3.9.4 Status and Logging Application 


The Status and Logging application provides an interface for multiple applications within 
a single window on a template to display an event list. 

Note: Events from the AFC application on the DDU can also be written to the 
event list. However, these are limited to events related to the application 
itself. AFC events or messages from the OBFTP are displayed in the main 
AFC window on the DDU. 

The event list is sorted by time and on event priority. The application can filter events so 
that only events of a certain priority or above are displayed. 

The Status and Logging application also provides one or more alarms triggered by events 
received that have priorities higher than a certain priority level. 

It is proposed that a Status and Logging application window be displayed on the On Trip 
template, and this window will show a bell symbol to indicate an alarm from any 
application running on the DDU, as illustrated in Figure 4. 
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Note: 


When an Agency has specified that the bell symbol is not required, the 
symbol is not included in the template provided to that Agency. For 
example, if an Agency is only interested in events written to the log file (as 
discussed in section 3.9.4.1), the bell symbol would not appear in the 
template for the Status and Logging application (refer to section 3.9.4.1). 
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Figure 4: Status and Logging Alarm Symbol (Typical) 


The Status and Logging application will also provide a large window view where the 
operator can choose to see all events in detail, organized on a priority and time basis. 
The operator will additionally be able to acknowledge or delete events as required. Refer 
to the screen-flow presentations in Table 5 for proposed screens demonstrating the 
Status and Logging event symbol and list. 


3.9.4.1 


Event Log 


The Status and Logging application writes all events and operator actions on the detailed 
events screen to a log file. The event log file has a maximum number of events/actions 
that it can store, with the oldest events/actions being deleted as required. 

The event log can be accessed from the Maintenance mode screen only. Maintenance 
personnel will be able to scroll through the log file to review the history of events and 
event screen operator actions on the DDU. 

Operators do not have access to the event log. Operators can only view events that have 
occurred during their shift. 

Refer to the screen-flow presentations in Table 5 for proposed screens demonstrating the 
viewing of the log file by maintenance personnel. 

The events that will be visible in the historical event log will include, but not be limited to, 
the following: 

• Operator, Maintenance and Supervisor logins and logouts, 

• Connection/disconnection of OBFTP with DDU AFC application, 

• DDU subsystem failures (where the failure does not stop the Status and Logging 
application from being loaded) 

• Normal DDU shutdown 

• DDU boot-up 
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3.9.5 Watchdog Application 

The Watchdog application monitors the health of the system using multiple watchdog 
timers. 

The watchdog timers must be re-armed by components at regular intervals. If any of the 
watchdog timers expire, the specified action is taken. This action can be one of the 
following (defined by the application that is registering for the counter): 

• The event is logged and the DDU is rebooted. 

• The event is logged and the DDU applications are restarted. 

• The event is logged only. 

Typical causes of watchdog timer expiration are applications operating incorrectly. 

The Watchdog application will attempt to log any watchdog expiration events and send 
these details to the Status and Logging application. Logging of these events cannot be 
guaranteed given the operational state of the device when performing this function. 

3.9.6 Management Application 

Control of the following DDU features is performed by the Management application: 

• LCD brightness 

• LCD contrast 

• Speaker volume 

The level of each setting can only be adjusted between CD-defined upper and lower 
limits by the operator. Each time the Management application starts or the operator logs 
off, the settings are reset to their CD-defined default levels. 

Maintenance tests are also controlled by this application. These include: 

• Screen Pattern 

• Read/Write Files 

• Speaker Test 

• Keyboard Test 


3.9.6.1 Device Configuration 

First-time configuration of the DDU (active cradle) is performed in Device Configuration 
mode (refer to section 3.11.3) and is detected and managed automatically during Power 
Up mode. 

The Management application provides the ability for an operator to change the device 
configuration by forcing Device Configuration mode to be entered. The logon information 
held in the DDU is used to restrict this function to operators logged on with a valid 
maintenance role. 
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J.9.6.2 Sleep Function Commented [dl]: Change Order #32 

The Management application also implements a sleep function on the DDU. The sleep 
function blanks the screen and renders all hotkey buttons inoperable except for the 
<Enter> hotkey that awakes the DDU. 

Note that no other DDU applications are affected, i.e., they continue to operate in 
background. However, they will not receive any operator hotkey inputs, and any output to 
the application window(s) will not be visible until the DDU is awoken. 

Refer to the screen-flow presentations in Table 5 for proposed screens demonstrating the 
sleep function. 


3.9.7 Monitor Application 

The Monitor application exercises control over the diagnostic serial port. It is responsible 
for all output information sent via the diagnostic port by either itself or indirectly from other 
DDU applications and provides a text based menu interface to allow various commands 
to be issued to itself or to be passed on to other DDU applications to process. 

The Monitor provides a mechanism for the Status and Logging application to send all 
event log data to the diagnostic port in real-time. 

The Monitor provides a small number of standard commands that a user can enter via 
the diagnostic port. These include but are not limited to the ability to display the contents 
of the Shared Public Data. 

The Monitor provides a mechanism for any DDU application to register with it a set of 
menus/commands. These menus/commands are extensions to the Monitor’s own 
command set and are displayed on the diagnostic port and can be typed in by a user, 
resulting in the appropriate DDU application being notified of the command. The DDU 
application in question then has the ability to perform an appropriate action. 

The Monitor provides a mechanism for any DDU application to request the output of data 
via the diagnostic port. 


3.9.8 _ FIM Stub/Test Harness Application commented [d 2 ] : com-vi 5.0.0-002 

The role of the FIM Stub/Test Harness application is to communicate to other DDU 

applications, via the DDU Shared Public Data, that LIM is enabled. This application will 

be deployed to all RFCS Agency coaches prior to the deployment of FIM. On coaches 

operated by Agencies that make use of FIM in the future, this application will be replaced 

by the 3 fd party provided FIM application, once it is available and has been certified. 

The FIM Stub/Test Harness application also implements a set of test commands via the 

DDU Monitor application. These test commands are limited to providing a mechanism to 

manually modify and validate the contents of the Shared Public Data variables that relate 

specifically to the implementation of FIM. 

The FIM Stub/Test Harness application may, therefore, be used as a development tool to 

provide simulation of various on-board operations to aid in the development of software 

Commented [d3]: COM-vl5.0.0-003 


3^8 3.9.9 AFC Application 


The AFC application controls the transfer of logon details to the applications, independent 
of the logon method. More details are outlined in section 3.11.4. 
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The AFC application is the application running on the DDU that communicates with the 
fare collection application running on the OBFTP. 

The AFC application provides flexibility to the template designer. This flexibility allows the 
placement of OBFTP screen information anywhere on the DDU display and allocation of 
the OBFTP function keys to any DDU hotkey button. This flexibility extends to allow 
different arrangements of OBFTP functions on different templates as required by different 
Agencies. 

Note: Refer to section 3.9.3 on the Template Manager, specifically the note 
regarding the mechanism that ensures that any interrupted AFC function 
sequence can always be completed. 

The AFC application provides the interface between the DDU and the OBFTP. This 
interface provides the mechanism for the AFC application to receive screen details from 
the OBFTP. In summary, the interface includes but is not limited to the following types of 
data and items: 

• Bitmaps (including icons) 

• Text 

• Boxes and lines 

The AFC application displays this information in the AFC window on the DDU. The AFC 
application requests a handle to this window created by the Template Manager: 

The AFC application draws all bitmaps, text, and boxes to the AFC main window. Icon 
bitmaps are drawn to one of the ‘n’ AFC logical hotkey windows (for example, AFC logical 
hotkey window 19). Logical hotkey windows are allocated to the AFC application to 
support all of the possible hotkey messages that are required by the OBFTP. 

Hotkeys consist of two parts: a picture (in the form of a bitmap) indicating the hotkey 
function and an OBFTP/DDU logical hotkey allocation indicating the key press details the 
OBFTP/DDU are expecting when this function is selected. Hotkey layouts are defined as 
decals in the template definition file. These decals define the physical positions of each 
hotkey. 

When the AFC application is processing an OBFTP screen, the OBFTP requests a 
particular decal or sequence of decals to be displayed. The AFC application passes this 
request on to the Template Manager, which is responsible for drawing the appropriate 
hotkey icons in the appropriate physical locations according to the decal’s definition. 

Note: Each time the AFC screen is updated (details change or entire screen 
changes due to a different state becoming active), details are sent from 
the OBFTP through the interface to the AFC application. 


3.9.8.1 3.9.9. OBFTP Screen Mapping 
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The AFC application windows are allocated to DDU physical resources by templates. A 
template defines the location and size of all windows on that template. 

Hotkey icons and actions are allocated to DDU physical resources by decals. Decals 
associate the DDU buttons with hotkey icons and actions, such as messages, and the 
windows to which the hotkey messages will be sent. Hotkey actions can also cause a 
change in which template is active. 

When a particular template is active the windows defined in that template become visible 
on the DDU. It is the responsibility of each DDU application to take control of a particular 
template window or windows during initialization and to draw information in those 
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windows. That information may or may not be visible depending on which template is 
active at any particular time. In addition any DDU application can directly request a 
change of template from Template Manager. 

DDU applications may also request at any time that a particular decal or set of decals 
(hotkey layouts) be associated with a template window. When that template window is 
active the associated decal will become visible on the DDU. 

Note: The AFC application on the DDU is common for all Agencies. The 
templates and decals, where function mappings are defined, can be 
customized for each Agency. The example screens that follow are for 
illustration purposes only, and do not reflect the template design of any 
Agency. 

The decals define exactly which the hotkey windows are defined, and therefore where the 
icons mapped to those windows, will appear. Each Agency will be able to define and use 
one or more decals with mappings that they require. 

This section illustrates the mapping of OBFTP displays and hotkeys in the AFC 
application and, depending on the templates and decals used, how this mapping 
translates to what is displayed on the DDU. Templates, decals and their corresponding 
icons are updated via CD. 

Note: The following template/decal descriptions are illustrative only; actual 
template/decal designs as agreed during customer screen-flow workshops 
are included in the screen-flow presentation in Table 5, as well as the 
same presentation in SEA-01050 Fare Transaction Processor (DR 102B) - 
Functional Specification [7]. 


Figure 5 below illustrates the logical layout of buttons and their corresponding hotkeys on 
the DDU. The 16 hotkey positions are numbered from 0 to 15 starting at the top left 
corner as shown. A decal defines the physical screen locations of logical hotkeys using 
these hotkey/button positions - as can be seen in the example decal - FareKeys below 
(see Figure 6). 
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# A decal with four buttons/keys defined. The images are referenced 

# by index into the images file. This decal might be used by the OBFTP 

# via the AFC application when it is displaying its Fares screen. 

decal(FareKeys) 

# Change Fareset key 

button(2) # Button/hotkey position 2 

image(42) #C:\AFC\BITMAPS\Navigation\SelectFareset.bmp 


message(ACTIVE,1024,0,226) 


button(4) # Button/hotkey position 4 

{ 

image(43) #C:\AFC\BITMAPS\Navigation\OverrideFareset.bmp 


message(ACTIVE,1024,0,227) 


# Group Fare key 

button(11) # Button/hotkey position 11 

image(44) #C:\AFC\BITMAPS\Navigation\GroupFare.bmp 


message (ACTIVE'l$£A, Q, 258) 


button(13) # Button/hotkey position 13 

{ 

image (45) #C: \AFC\BITMAPS\Navigation\ReverseTxn.bmp 


message (ACTIVE 0MM ,0,257) 


Figure 6: Example Decal (FareKeys) 

The icons for the hotkeys defined in the FareKey decal above are illustrated below in 
Figure 7. The icons in Figure 7 are examples for illustrative purposes; refer to the screen- 
flow presentation in Table 5 for proposed icons. Given these icons, if the OBFTP 
requested this decal to be displayed via the AFC application, the DDU would look like 
Figure 8, when the template window owned by the AFC window becomes active. 
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A$ 

-* $$> 

- 

Figure 7: FareKeys Screen Icons (Example) 

The functions in Figure 7 can be allocated across any number of decals, as required by, 
and configured for, each Agency. 



Figure 9 illustrates another example decal called MoreFareKeys, which defines 5 
hotkeys, some of which are designed to be handled by the OBFTP via the AFC 
application, i.e. OBFTP Settings, Select Trip and Select Run. 

The other two keys are examples of keys that trigger a change to the active 
template/window and send messages destined for DDU applications other than the AFC 
application. For example, the Event Log key changes template/window to 
StatLog/EventLogWindow. The EventLogWindow template window might be controlled 
by the Status and Logging application, which would be drawing the Event Log information 
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in the EventLogWindow template window. As can be seen from this example decal, 
message() actions can be directed at either a specific template window such as 
EventLogWindow or to ACTIVE (the ‘active’ window). By directing messages to the active 
window decals can be designed to be more generic and reusable. In a similar vein, 
template() and window)) actions refer to templates and window specifically or a TDL 
designer can use the previous)) action which causes the Template Manager to display 
the previous template/window pair. 

Apart from the destination window, each message() action defines three numbers, in the 
following order: 

• The message identifier: The Windows CE message number used by the DDU 
applications to identify that the message is a keypress message from Template 
Manager. By convention 1024 is used. This is the minimum value that can be used. 
Lower values are reserved by Windows CE for other purposes. 

• A wParam number: A value used to identify which key was pressed by the DDU 
applications, 

• An IParam number: A value used to identify which key was pressed by the OBFTP. 
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rrorLog.bmp 


SFTPSettings.bmp 


slectTrip.bmp 


jlectRun.bmp 
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The OBFTP and the DDU Applications have the ability to ‘overlay’ decals on top of each 
other via Template Manager. As an example, Figure 11, illustrates the effect of overlaying 
the MoreFareKeys decal on top of the FareKeys decal. It is important to note that if an 
overlay decal defines a key in a button position that already has a key defined in an 
underlying decal, the key in the overlay decal takes precedence and is displayed to the 
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xxxx 
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Figure 12: OBFTP Full Window (Example) 

When the AFC main window is present on a template in a size less thant 240 x 128 Commented [d5]: C0M-vi 5.0-004 

pixels, the screen is clipped. The reference point for clipping is the top left corner of the 

OBFTP screen and the top left corner of the AFC main window. Depending on the size of 

the AFC main window, and the current state of the OBFTP application, data may or may 

not be clipped. Refer to the screen-flow presentations in Table 5 for proposed application 

window sizes and arrangements on various templates for each Agency. 

To this point the figures have been mostly concerned only with mappings, and application 
window detail has not been shown. Figure 13 illustrates the example display in Figure 12 
applied to a template with an additional application window (Status and Logging) and a 
smaller AFC main window. The same detail is drawn in the AFC application window in 
both cases to illustrate the clipping of the window contents. Note that the contents of the 
Status and Logging window has not been drawn for illustrative purposes. 
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By convention, when a hotkey press message is received, the AFC application passes 
the message’s IParam number on to the OBFTP. It is this value that identifies to the 
OBFTP which hotkey has been pressed. The OBFTP then takes the appropriate actions. 
For example, the FareKeys decal indicates that if the Group Fare key was pressed the 
AFC application would pass on the IParam number (258) to the OBFTP. 

Also by convention, all DDU applications use the message's wParam number to identify 
which hotkey was pressed. For example, the MoreFareKeys decal indicates that if the 
DDU Settings key were pressed a message would be sent to both the ‘AfcWindow’ 
template window (controlled by the AFC application) and the ‘MgmtWindow’ template 
window (controlled by the Management application) as well as a change of active 
template. Both the AFC and Management applications use the wParam number (313) to 
identify this key. 

Note: Each time the OBFTP screen is updated (details change or the entire 
screen changes due to a different state becoming active), details are sent 
through the interface to the AFC application. The OBFTP may request 
different decals via the AFC application on state changes so that old 
hotkey icons can be cleared and associated hotkey messages ignored. 


3.9.8.2 3.9.9.: Time Reference 

The DDU hardware has an RTC as described in section 2.3.2.7 (in SEA-01047 Driver 
Display Unit (DR 103A) - Hardware Specification [6]) to maintain accurate time and date. 
The DDU time is updated from a source at the Central System during authentication with 
the DAC. 

The time can be displayed on the DDU by any application running on the DDU. The 
location for time display will be as specified in the DDU templates and as agreed to by 
the Agencies. Refer to the screen-flow presentations in Table 5 for more details. 

3,9^8 3.9.10 Third-Party Applications 

The DDU supports operation of up to six third-party applications. 

Third-party application functionality is bound to hotkey presses in exactly the same way 
as for the AFC application. Hotkeys can be allocated to any location on any template. 
Access to third-party application functionality when an operator has not correctly logged 
on is not restricted by the DDU. Allowing access to functionality under these 
circumstances is up to the individual third-party applications. 


1MMM 3.9.10.1 Community Transit (CT) Application (DR 103.07) 

• The CT application provides a user interface to the following third-party devices: GFI 
Electronic Registering Farebox (Version 4 and Version 7) (DR 103.05) 

• Transit Signal Priority (TSP) 

• Destination Sign 

The interface is through a single RS485 serial port as specified in SEA-01047 Driver 
Display Unit (DR 103A) - Hardware Specification [6]. The interface is to a third-party 
device (McCain Interface Board) that provides an interface to control and receive 
information from the on-board equipment listed above. 
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The DDL) functionality required for the CT integration is essentially to provide a display 
and keypad interface to the CT on-board equipment. 

Associated functionality, including on-board equipment and networking, is to store, 
maintain, and download files required for configuring or interfacing with the CT devices. 
The CT application will provide hotkey assignments and message displays to provide the 
following functionality, either as a consequence of some associate action (for example, a 
logon) or as a direct command from the operator. 

• Send logon information to the devices 

• Request and display the connectivity status from the TSP 

• Send trip information at the beginning of each trip to the devices 

• Send the sign configuration file based on an effective date 

• Send logoff notification to the devices 

Note: Non-fare-card ridership is an OBFTP function and described in SEA-01050 
Fare Transaction Processor (DR 102B) - Functional Specification [7], As 
per workshop discussions and responses to SEA-01422 ERGRFI 00232 
Attachment C06AppGCT BizReql 1_22_04 [33], the DDU does not send 
details of non-fare-card ridership to the farebox. 

Note: As per workshop discussions and responses to SEA-01422 ERGRFI 
00232 Attachment C06AppGCT BizReql 1_22_04 [33], the DDU does not 
need to know the farebox type (4 or 7) installed on any vehicle, as the 
keyboard emulation is not required. Additionally, all other required 
communication to the farebox is independent of farebox type, or the 
differences are handled by the third-party interface board. 

Figure 14, Figure 15, and Figure 16 illustrate the process flow for the CT application on 
the DDU. The following subsections describe the process flow components in more 
detail. 
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Figure 16: CT Application Operational Flow - Maintenance Mode 


3.9.9.1.1 3.9.10.1.1 CT Data 


A number of data files are required in support of the CT integration. These include: 

• A pending destination sign configuration file: 

o This file will be downloaded to and reside in the DDU. As discussed in section 
3.5.3, a manifest is included in the DDU CD, notifying it of the file to download. 
The download is part of the CD download to the DDU from the DAC. 
o The destination sign files vary between buses. 

Note: The DDU will store a single version of the sign configuration file. After a 
pending destination sign configuration file is uploaded to the destination 
sign, it is deleted from CD. 
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o The trip information includes: 

■ Run 

■ Trip 

■ Start time 

■ Sign message number 

Note: The trip data file is also included in the OBFTP CD. The trip data file on 
the DDU is only required when the OBFTP is not serviceable; at other 
times the OBFTP performs trip management. 


3.9.9.1.2 3.9.10.1.2 CT Functionality 


3.9.9.1.2.1 3.9.10.1.2.1 Startup 

At startup, the DDU performs the following functions: 

• Queries the McCain interface board for connectivity and status of the CT devices and 
displays the result. 

• If the application and/or data files are not as required in the manifest, attempts to 
download the files from the DAC. 

• Send the appropriate (effective) destination sign file to the McCain interface for 
transfer to the destination sign, and display the result of the action. Note that sending 
the destination sign file is available as an ad-hoc maintenance activity from the DDU. 


3.9.9.1.2. 2 3.9.10.1.2.2 Operator Logon 


The operator performs either a DDU manual logon or OBFTP-available logon as 
described in section 3.11.4. 


Depending on the type of logon performed, the operator: 

• Will either have entered an operator ID and password, or have entered a password 
and presented an operator card. 

• The operator will select route, run, and trip information from information defined in 
configuration data. Refer to the screen-flow presentations in Table 5 for proposed 
screens for operator logon and route, run, and trip selection. 


3.9.9.1.2. 3 3.9.10.1.2.3 Update Devices with Trip Information 


After the operator logon and the entering of the trip number: 

• The DDU sends the following information to the McCain interface for transfer to the CT 
devices: 
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As per section 3.9.10.1, workshop discussions and responses to SEA-01422 ERGRFI 
00232 Attachment C06AppGCT BizReql 1_22_04 [33] concluded that the DDU does not 
send details of non-fare card ridership to the farebox. Consequently, all revenue 
collection activities (other than those associated with logon in section 3.9.10.1.2.2, and 
those associated with updating trip information in section 3.9.10.1.2.3), including non-fare 
card ridership, are implemented by the OBFTP. 

Also as per section 3.9.10.1, workshop discussions and responses to SEA-01422 
ERGRFI 00232 Attachment C06AppGCT BizReql 1 22 04 [33] concluded that the DDU 
does not need to provide farebox keyboard emulation. 


3.9.9.1.2. 5 3.9.10.1.2.5 Trip and Run Processing 


Trip and run processing is initiated from the DDU and will be controlled directly either 
through the DDU AFC application or through the OBFTP if it is available. 

At every change of run, route, or trip, updated information is sent to the McCain interface 
for transfer to the CT devices as was done after the initial logon. 


3.9.9.1.2. 6 3.9.10.1.2.6 Ridership Counter Hotkey Processing 

A number of hotkeys will be defined to perform ridership counter functionality in the 
OBFTP (refer to SEA-01050 Fare Transaction Processor (DR 102B) - Functional 
Specification [7]). The same hotkeys will also issue a request on the McCain interface for 
the farebox ‘dump’ key to be pressed. The DDU template manager issues the requests to 
the DDU AFC and McCain interface applications each time a counter key is pressed; the 
applications themselves are separate and independent of one another. 


3.9.9.1.2. 7 3.9.10.1.2.7 Operator Logoff 

The operator performs either a DDU manual logoff or OBFTP-available logoff, depending 
on the method of logon, as described in section 3.9.5. 

The DDU will send a notification of the logoff event to the McCain interface for transfer to 
the CT devices. 


3.9.9.1.3 3.9.10.1.3 McCain Interface Specification 


A preliminary McCain interface specification has been provided to ERG for review and 
comment. Additional breakdown of messages is provided in the CT McCain Interface 
Document [33]. A consolidated McCain interface specification is required for inclusion as 
an attachment to that document. 


3^^2 3.9.10.2 King County Metro (KCM) Application (DR 103.06) 


The KCM application provides an interface to the RCU . when the DDU is in Limited 
Integration Mode (LIM) only. In LIM, the functions described below are enabled. In FIM, 


application to achieve its required functionality are not accessed by this application. 

Instead the KCM application allows the third-party-provided FIM application to gain 

access to these template resources for its use. 
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Refer to the SEA-00241 Radio Control Unit (DR103.06) [34] for details of the hardware 
and software design details for the RCU. 

The following functions will be supported by the KCM application: 

• RCU logon 

• Priority request to talk (PRTT) 

• Request to talk (RTT) 

• Select preprogrammed text message (future) 

• Select channel 

• PA control 

• Select preprogrammed public service announcement (PSA) (future) 

• Replay last PSA (future) 

• PA volume adjustment 

• Handset volume adjustment 

• Radio setting adjustment 


3^9A1 3.9.10.2.1 RCU Logon 

An RCU logon will be attempted whenever a new logon occurs or whenever the route/run 
information is changed. 

As part of the AFC application, a default logon will be sent to the RCU if a valid operator 
logon has not occurred within a configurable number of retries. 

The number of retries before the default logon is sent should be configured to be less 
than the configurable number of retries before the operator logon card is blocked. 

The default logon information is: 

Route/Run: 444/44 

Operator ID: 4 

Fallback channel: 4 

Refer to the screen flows in Table 5 for proposed screens for the RCU normal and default 
logon cases. 


3^9^2 3.9.10.2.2 KCM Application Display 

In addition to the functions supported, the following information is displayed in the KCM 
application window when visible on the DDU display: 

• Emergency Alarm Status 

The emergency alarm acknowledgement message from the RCU is normally to flash 
one colon (:) in the RCU time message. As per section 3.9.9.2 the DDU will obtain 
time from the Central System via the DAC. On request from KCM, a flashing bell 
symbol will be displayed in the corner of the KCM application window. Refer to the 
screen-flow presentation in Table 5 for more detail. 
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• Request to Talk Indications 

The RCU updates three status indicators in response to an RTT, PRTT, or PA 
request, either from the operator or the DCC. The three (3) indicators correspond to 
the ACK (acknowledge), CALL, and PA signals, which the RCU sends to the DDU in 
response to operator actions or requests to the operator from the DCC. 

The DDU will show the state of all three (3) status indicators at all times in the KCM 
RCU window. Refer to the screen-flow presentation in Table 5 for the proposed layout 
of the KCM application window and arrangement of the indicators. 

• Preprogrammed Text Message List 

The preprogrammed text messages feature is future functionality. 

• Fallback Channel In Use 

The fallback radio channel (1 to 4) in use will be displayed in the KCM application 
window when in voice mode. The fallback channel number is defined in configuration 
data. 

• Preprogrammed Public Service Announcement List 

The preprogrammed public service announcements feature is future functionality. 

• Message/Status Alerts 

The KCM application will include the display of an RCU message, as well as the RCU 
status. Only messages/status alerts from the RCU that are for the attention of the 
operator will be displayed in the KCM application window on the DDU. 

The messages and status alerts from the RCU are tokenized, meaning that only an 
identifier is sent; the actual strings are part of the KCM application on the DDU. This 
enables the RCU message strings displayed on the DDU to be changed (at design 
time) from the original RCU messages. 

The RCU messages to be displayed by the DDU include the following: 
o All call 
o PA call 
o Group call 
o Single call 

Note: Other RCU messages will be replaced by blank strings so not displayed to 
the operator. 

The RCU status alerts to be displayed by the DDU include the following: 
o Pis Use Voice (formerly No RTT/PRTT in RCU) 
o Pick up handset 
o Modem failure 
o SP RCVR failure 
o EA switch failure 
o MDU failure 

Note: Other RCU status alerts will be replaced by blank strings so not displayed 
to the operator. 


SEA-01048 
Revision 16.0 122 


ERG Confidential © ERG 2010 
To be disclosed only to Agency personnel who 


! Feb 2010 


Page 52 of 2263 





Central Puget Sound Driver Display Unit (DR 103B) - 

Regional Fare Coordination System Security Level 3 Functional Specification 

The proposed KCM application window arrangement and proposed hotkey icons are 
illustrated in the screen-flow presentation in Table 5, 

Sequencing of RCU operation is described in the SEA-00241 Radio Control Unit 
(DR103.06) [34], As the RCU operation is essentially unchanged from the prototype 
equipment used by KCM, and as the DDU is only a keypad and display interface to the 
RCU, operator operations should not be impacted. 


3^^3 3.9.10.3 VLU Integration 


The addition of the VLU should not affect the functionality of any of the applications. If 
any application functionality is required to change when the VLU is installed, the 
application will require updating as applicable. 

The DDU includes an application to interface with the OBFTP for fare collection 
functionality. 

The VLU (and/or other third-party equipment) can exchange information or data with the 
OBFTP through the DDU as described in section 3.9.10.4 using public data. For 
example, the VLU could provide the OBFTP (and other equipment) with vehicle location 
information by updating appropriate public data. 

Figure 17 below illustrates the interlace method between the VLU and the OBFTP. Each 
of the devices has an application running on the DDU that manages access to the public 
data as well as the user interface functionality required by the device. 



Commented [d8]: Change Order 1 
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Figure 17: VLU to OBFTP Interface 

.9.10.4_FIM Application 

The FIM application is responsible for providing an interface between the VLU and other 
DDU applications and, indirectly, the OBFTP. 

The following functions will be supported by the FIM application: 

» Configuration of LIM/FIM based on absence/presence of VLU hardware. 

» Operator login/loqout process (optional), 

. Route/run entry and trip selection, 

» Automatic next trip selection. 

» Automatic fare change at zone boundaries 


3.9.10.4.1 Configuration of LIM/FIM 
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Other DDU applications and the OBFTP application will read this indication from the 

Commented [d9]: COM-vl 5.0-007 ] 

Note: The population of the Shared Public Data variables to indicate the 
configuration of FIM or LIM must be done as early as possible during the 

( Commented [dlO]: COM-vl5.0-007 ) 


3.9.10.4.2 Operator Loqin/Logout Process 

While operator login/logout is generally performed by the AFC or OBFTP applications, in 

FIM, the FIM application may, optionally, automatically reguest an operator login/logout. 

An operator login reguest from the FIM application involves the following seguence of 

events: 

1. The FIM application communicates the appropriate operator login information to the 
AFC application through the Shared Public Data. 

2. The AFC application will then validate the information or pass the information to the 
OBFTP application to validate. The result of this validation is then communicated 
back to the FIM application through Shared Public Data variables. If this step is 
successful, the login process is completed and the login information is fed back to the 
other DDU applications including the FIM application through Shared Public Data 
variables and the DDU device mode is set to "Off-Trip”. 


3. The FIM applicatic 

Selection screens 


An operator logout reouest from the FIM applic 
events: 

1. The FIM application communicates the appr 
AFC application via the Shared Public Data. 

2. The AFC application will then validate the ii 
OBFTP application to validate. The result 
back to the FIM application through Shari 
successful, the logout process is completed 
the other DDU applications including the Fit 
variables and the DDU device mode is set tc 


3. The AFC application or OBFTP application follows the 

outlined in section 3.11.4 or 171 respectively. 

Note: A reguest by the FIM application to perforrr 
operation through the Shared Public Data ' 

unsuccessful unless the DDU/OBFTP are in 

accept such a reguest. 


3.9.10.4.3 Route/Run Entry and Trip Selection 
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The AFC application will then validate the trip information or pass the trip information to 

the OBFTP application to validate. The result of this validation is then communicated 

back to the FIM application through Shared Public Data variables. If this step is 

successful, the trip change is completed, the trip information is fed back to the other DDU 

applications including the FIM application through Shared Public Data variables and the 

DDU device mode is set to “On-Trip". 

Note: An agency-defined, unique Trip ID will be provided by the Agency to both 

the FIM application and the other DDU applications/OBFTP application. 

Across a year’s major services changes and other interim Configuration 

Data (CD) distributions, these Trip IDs will not be re-used. Also, for the life 

of a major service change, a Trip ID will always refer to the same trip. 

These two conditions are required to avoid undetected mismatches in 

datasets between the FIM application and the AFC/OBFTP applications. 

Note: A request by the FIM application to change trip information through the 
Shared Public Data variables will be deemed unsuccessful unless the 
DDU/OBFTP are in an appropriate mode to accept such a request. 


3.9.10.4.4 Automatic Next Trip Selection 

in FIM. the FIM application is responsible for providing automatic next trip selection 

based on vehicle location. This function involves the following sequence of events: 

1. At a point in time just prior to reaching the end-of-trip location, the FIM application 
directs the DDU to display a message asking the driver to confirm the change to the 
next trip. At the same time it displays the “Start Next Trip” hotkey for the driver to 
press to trigger this confirmation. 

2. After the driver presses the “Start Next Trip” hotkey, the FIM application 
communicates the next trip’s information to the AFC application via through the 
Shared Public Data. 

3. The AFC application will then validate the trip information or pass the trip information 
to the OBFTP application to validate. The result of this validation is then 
communicated back to the FIM application through Shared Public Data variables. If 
this step is successful, the trip change is completed, the trip information is fed back to 
the other DDU applications including the FIM application through Shared Public Data 
and the DDU device mode is set to "On-Trip". 

4. New trip and fare information is displayed on the DDU. 

Note: An aoencv-defined. unioue Trip ID will be provided bv the Agency to both 

the FIM application and the other DDU applications/OBFTP application. 

Across a year’s major services changes and other interim Configuration 

Data (CD) distributions, these Trip IDs will not be re-used. Also, for the life 

of a major service change, a Trip ID will always refer to the same trip. 

These two conditions are reguired to avoid undetected mismatches in 

datasets between the FIM application and the AFC/OBFTP applications. 


Note: A reguest bv the FIM application to change trip information via the Shared 

Public Data variables will be deemed unsuccessful unless the 

DDU/OBFTP are in an appropriate mode to accept such a reouest. 


SEA-01048 
Revision 16.0 122 


ERG Confidential © ERG 2010 
To be disclosed only to Agency personnel who 


! Feb 2010 


Page 55 of 2263 




















































Central Puget Sound 

Regional Fare Coordination System 


Security Level: 


Driver Display Unit (DR 103B) - 
Functional Specification 


Automatic Fare Change at Zone Boundaries 


1. The OBFTP sets the initial distance code at the start of a trip. 

2. When the FIM application determines the current distance 
change based on the vehicle’s location, it will communic 
OBFTP through Shared Public Data variables. 

3. If the OBFTP a 

current distance 

the current diste 

successful throt 

FIM application 

variables 

Note: The OBFTP has a mechanism to notify the FIM application whether or not 

the initial distance code for the current trip has been overridden by the 

driver through Shared Public Data variables. 

Note: The initial trip distance code, fare tablets) and peak/off-peak designator, 
will come from RFCS CD as exported by the Agencies. The default 
distance code can be overridden by the driver and the driver retains the 
ability to manually select between the Peak/Off Peak fare tables for the 


Note: Distance code changes initiated by the FIM application will be limited to 

the valid distance codes in the designated fare tables for the trip. 

Note: A reguest by the FIM application to change distance code information 
through the Shared Public Data variables will be deemed unsuccessful 

unless the OBFTP is in an appropriate mode to accept such a reguest. [_ f commented [dll]: Changed Order #32 



3.10 DDU Public Data 

The DDU maintains a number of public variables that can be accessed by third-party 
applications, for example, logon details updated by the AFC application described in 
sections 3.9.5, and 3.11.3. 

The development kit provided to third party developers will include details of the DDU 
public data variables available and how they are used. Refer also to section 3.6.1 that 
provides more detail regarding the development kit. 

The following subsections outline the processes for the declaration and registration of 
public variables, as well as the access to public data. 


3.10.1 Public Variable Declaration and Registration 

A DLL for creating and managing a shared data segment is included as part of the DDU 
executive applications. The DLL exposes an API that permits applications to set or get 
variables stored within the shared data segment. The variables stored within the shared 
data segment can range from simple native data types to complex structures. 
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The expectation is that the definition of public variables will be an infrequent occurrence, 
and therefore, as new variables are required, a new DLL will be created and downloaded 
to the DDU. 


3.10.2 Public Variable Access 

As per the descriptions in section 3.10.1, applications can get access to data stored in 
the shared data segment using appropriate API calls. 

Applications can manually get the state of public variables or optionally register with a 
call-back mechanism (call-back function, event, Windows message) for notification when 
variables change. 


3.11 DDU Operation 

3.11.1 Power Up Mode 

Power Up mode initializes the DDU before entering operation. The start-up process flow 
chart is illustrated in Figure 18. 
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J.11.1.1 Entry Conditions 

Power Up mode is entered when the ignition switch of the vehicle is turned on. 


Sequence of Events 

Power Up mode involves the following sequence of events: 

1. The Application Manager application is started. 

2. The Application manager specifies the path of the template file to the Template 
Manager. 


3. The Template Manager creates the main window on the DDU. 

4. The Template Manager parses the template file for all defined windows. 

5. The Template Manager creates all windows and initially hides them. 

6. The Template Manager sizes, positions, and shows all windows in the first template, 
o If any of the Template Manager initialization steps fail: 

a Application Manager enters the Out Of Service mode and displays the Out Of 
Service screen. 

b The DDU powers off after a short period. 

7. The Application Manager application performs power-on self-tests, 
o If any of the self-tests fail: 

a Application Manager enters the Out Of Service mode and displays the Out Of 
Service screen. 

b The DDU powers off after the OK key is pressed. 

8. The Application Manager checks to see if a valid DDU application manifest exists. As 
per section 3.5.3 a valid DDU application manifest includes the DDU executive 
applications, the AFC application, third-party applications, and associated data files. 

o If a valid DDU application manifest exists: 

a The Application Manager starts all applications according to the DDU application 
manifest. Refer to section 3.5.3 for detail on DDU applications, and section 3.6 
regarding application certification, 
o If a valid DDU application manifest does not exist: 
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a The Application Manager enters the Out Of Service mode and displays the Out Of 
Service screen. 

b The DDU powers off after the OK key is pressed. 

1. The Management application checks if the DDU has been configured, i.e. device 
configuration is complete. If the configuration is not complete the device enters 
Device Configuration mode. 

2. If device configuration is complete, this sequence ends. The device enters Startup 


3.11.1.3 Exit Conditions 

Power Up mode is exited when any of the following conditions occur: 

• The Power Up mode sequence of events is complete. The DDU enters Application 
Startup mode. 

• Any of the initialization steps fail. The DDU operation is dependent on the failure but 
will generally enter Out Of Service mode and display the Out Of Service screen. 


3.11.2 Startup Mode 

Startup mode performs CD transfer and checks for a valid CD set and the need for an 
application upgrade. The startup process flow chart is illustrated in Figure 19. 
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Entry Conditions 

Startup mode is entered after successful completion of Power Up mode. 

Sequence of Events 


The Startup 


;uence of events is: 
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1. The Application Manager enters a CD transfer mode and attempts to retrieve a valid 
CD set from the DAC. 

2. The Application Manager checks to see if any application modules were downloaded 
from the DAC. 

o If application modules were downloaded: 
a Upgrade to new applications and data files, 
b Enter Power Up mode, 
o If no application modules were downloaded: 
a Continue this sequence. 

3. The Application Manager checks to see if a valid CD set exists, 
o If a valid CD set exists: 

a This sequence ends and the DDU enters Logon mode, 
o If a valid CD set does not exist: 

a The Application Manager displays the Incomplete CD screen. 

4. In the Incomplete CD screen the user has two choices, i.e. to press the Device 
Configuration key or the OK key. 

o If the Device Configuration key is pressed: 
a The DDU enters Device Configuration mode, 
o If the OK button is pressed: 
a The DDU begins Startup mode again. 

Note: In step 1, CD transfer requires the vehicle WDOLS to be within range of 
the depot access point. Note also that CD transfer is dependent on a 
number of retries and inactivity timeout. 

[Note: Startup mode can be entered from either Power Up mode immediately 

after the DDU is powered up or from Logon mode after an operator logoff. 

In the former case, the DDU will be configured to obtain only specially 

marked CD payloads, i.e., actionlist payloads, from the DAC. This is done 

to reduce CD download times before going on-shift initially after power-up. 

Any changed CD payloads that are not marked as “special” will not be 

downloaded at this time. Subsequently, when CD transfer is initiated after 

the first Operator logoff after power-uo. the device will be configured to 

Commented [dl2]: RFCS RFI 236, SERM #1-001128, EQP- 
012 Managing Data Transfer 

3.11.2.3 Exit Conditions 

Startup mode is exited when the following conditions occur: 

• After a valid CD set has been found. 

• After pressing the Device Configuration key in the Incomplete CD screen. 
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3.11.3 Device Configuration Mode 

This section describes those actions that take place whenever an uninitialized device is 
being configured for usage. 

The following information is stored in the DDU active cradle: 

5. DDU I/P address 

6. Bus network I/P address mask 

7. DAC I/P address 

8. DAC gateway I/P address 

9. WDOLS client username and password 

10. WDOLS management username and password 

11. Vehicle ID 

12. Source Participant ID (i.e., the Agency owning the OBFTP)| 

Not e : The gateway I /P addr e ss w ill change as m i grat i on from L I M to FIM i s 
mad e . For L I M, th e gat e way w ill b e th e addr e ss of th e on - board WLAN 

br i dg e . For F I M, th e gat e way w il l b e chang e d to the addr e ss of th e VLU 

through wh i ch th e DDU transf e rs w ill take p l ac e . R e f e r a l so to sect i on 
3.9.6.1 on d e v i c e configurat i on and ma i nt e nanc e mod e functiona li ty. 

Note: The Source Participant is the Agency owning the OBFTP. In the case 
where ST buses are operated by other Agencies, e.g., KCM, KCM would 
be the Source Participant. ST is the Service Participant, i.e., the Agency 
indicated in usage data as owning the transactions. Note that the Service 
Participant comes from configuration data and is associated with the 
route/run in operation. 
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Note: 


Maintenance mode in Figure 20 refers to the Supervisor Watchdog 
application when a valid maintenance role logon exists. 


Entry Conditions 

When a DDU has not been previously configured (i.e., it is an uninitialized device) or it 
has been located on a different vehicle, the DDU will need to be set up to match the 
hardware in the vehicle. 

If the DDU has been previously configured, the Management application can be used to 
change the device configuration if necessary. Refer to section 3.9.6.1. 
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During the Device Configuration mode sequence, the DDU will display one of the 
Configuring Device screens shown in Figure 21. Refer to the 'Configure Device’ screens 
in the screen-flow presentations in Table 5 for the proposed screens. 

Device Configuration mode involves the following steps: 

1. Configure the DDU cradle with the DDU I/P address and the bus network I/P address 

2. Set the DAC I/P address. 

3. Set the DAC Gateway I/P address. 

4. Set the WDOLS I/P address 

5. Set the WDOLS client username and password. 

6. Set the WDOLS management username and password. 

7. Set Vehicle Number. 

8. Set the participant ID. 

Note: For CT buses, the vehicle ID will be read out of the TSP tag and updated 
into the cradle automatically at start-up/log-on, so this "set” function is an 
initial, day 0, default value. 

Rioter— DAC Gat e way i n LIM mod e w ill b e via th e WDOLS, wh ile in F I M mod e th e 
gat e way w ill b e v i a th e VLU, 

The device configuration sequence is as follows: Commented [dl4]: Change Order #32 
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1. The DDU displays the Equipment not Configured screen details. Refer to the 
‘Equipment not Configured’ screens in the screen-flow presentations in Table 5 for 
the proposed screens. 

a When the <OK> hotkey is pressed the configuration process continues. 

2. The DDU displays the Set Device IP screen. Refer to the 'Set Device IP' screens in 
the screen-flow presentations in Table 5 for the proposed screens. 

a When the Device I/P address is entered and the <OK> hotkey is pressed the 
configuration process continues. 

3. The DDU displays the Set Device IP Mask screen. Refer to the 'Set Device IP Mask’ 
screens in the screen-flow presentations in Table 5 for the proposed screens. 

a When the Device I/P address mask is entered and the <OK> hotkey is pressed 
the configuration process continues. 

4. The DDU displays the Set DAC IP screen. Refer to the 'Set DAC IP' screens in the 
screen-flow presentations in Table 5 for the proposed screens. 

a When the DAC I/P address is entered and the <OK> hotkey is pressed the 
configuration process continues. 

5. The DDU displays the Set Gateway IP screen. Refer to the ‘Set Gateway IP' screens 
in the screen-flow presentations in Table 5 for the proposed screens. 

a When the Gateway I/P address is entered and the <OK> hotkey is pressed the 
configuration process continues. 

6. The DDU displays the Set WDOLS IP screen. Refer to the 'Set WDOLS IP' screens 
in the screen-flow presentations in Table 5 for the proposed screens. 

a When the WDOLS I/P address is entered and the <OK> hotkey is pressed the 
configuration process continues. 

7. The DDU displays the Set WDOLS Client Username and Password screens. Refer to 
the ‘Set WDOLS Client Username & Password' screens in the screen-flow 
presentations in Table 5 for the proposed screens. 

a When the WDOLS Client Username has been entered and the <OK> hotkey is 
pressed the configuration process continues. 

b When the WDOLS Client Password has been entered and the <OK> hotkey is 
pressed the configuration continues. 

8. The DDU displays the Set WDOLS Management Username and Password screens. 
Refer to the ‘Set WDOLS Management Username & Password’ screens in the 
screen-flow presentations in Table 5 for the proposed screens. 

a When the WDOLS Management Username has been entered and the <OK> 
hotkey is pressed the configuration process continues. 

b When the WDOLS Management Password has been entered and the <OK> 
hotkey is pressed the configuration continues. 
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9. The DDU displays the Set Vehicle ID screen. Refer to the ‘Set Vehicle ID' screens in 
the screen-flow presentations in Table 5 for the proposed screens. 

a When the Vehicle ID is entered and the <OK> hotkey is pressed the configuration 
process continues. 

10. The DDU displays the Set Participant ID screen. The maintenance personnel is 
prompted to input the Source Participant ID, for the device that is being configured. 
Refer to the ‘Set Participant ID' screens in the screen-flow presentations in Table 5 
for the proposed screens. 

a When the Participant ID is entered and the <OK> hotkey is pressed the 
configuration process continues. 

11. If writing the configuration parameters was unsuccessful, the DDU displays the 
Configuration Unsuccessful screen. Refer to the ‘Configuration Unsuccessful' 
screens in the screen-flow presentations in Table 5 for the proposed screens. 

a When the <OK> hotkey is pressed the configuration process starts from the 
beginning. 

12. If writing the configuration parameters was successful, the configuration process 
ends and the DDU moves to Startup mode. 


3.11.3.3 Exit Conditions 


1. On successful completion of Device Configuration mode, the DDU will progress to 
Startup mode. Refer to section 3.11.2 for details of the Startup mode. 

2. If the Device Configuration mode is not completed, the Device Not Configured screen 
details is displayed. Refer to the ‘DDU Device not Configured' screen in the screen- 
flow presentations in Table 5 for the proposed screen. 


3.11.4 Logon Mode 

Logon mode provides access to device functionality given that correct operator details 
are provided. 

Logon details are updated to the DDU public data area (refer to section 3.9.10.4). This 
enables all DDU applications access to logon details (the same applies for logoff details) 
from a single logon event. 

Logon details also include the role associated with the logon, as this is used to determine 
if maintenance functionality as provided by the Management application is accessible. 
Refer also to section 3.9.6 for details of the Management application. 

Note: Access to third-party application functionality when an operator has not 
correctly logged on is not restricted by the DDU. Allowing access to 
functionality under these circumstances is up to the individual third-party 
applications. 


3.11.4.1 Entry Conditions 
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Note: The logon method (i.e. automatic or manual) is configurable by an Agency 
in OBFTP configuration data. If the AFC application cannot process logons 
(i.e. the OBFTP is not available) only manual logons are possible from the 
DDU regardless of the method configured in CD by the Agency. 

[Note: In FIM. a mechanism exists for a manual login to be triggered bv the 3 rd 

party provided FIM application. This mechanism involves the FIM 

application communicating login information to the AFC application 

through the Public Shared Data. Refer to section 3.9.10.4.2 for more 

Commented [dl5]: Change Order #32 


Sequence of Events 

The Logon mode flow chart is illustrated in Figure 22 and described below for manual 
and automatic (smart card using OBFTP) methods of logging in. 



Figure 22: Logon Mode Flow 

The AFC application determines the status of the OBFTP. 

• If the OBFTP is faulty or no connection can be established, DDU manual logon is 
performed as outlined in 3.11.4.2.1. 

• If the OBFTP is functional and a connection is established, OBFTP-available logon is 
performed as outlined in 3.11.4.2.2. Note that OBFTP-available logon will be either 
automatic or manual depending on the method configured in CD for each Agency. 

Note: Selection of either automatic or manual logon is configurable per Agency 
requirements. See SEA-00805 ERGRFI 00188 [18] for additional 
information and issues related to Card Logon. 
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Note: Once logon information has been written to public data as illustrated in 
Figure 22, this information is available for third-party application logons 
such as the KCM RCU. 

Note: The logon information in public data will also include details of invalid 
logons, in particular an indication that a default KCM RCU logon should be 
performed by the RCU application. Refer also to section 3.9.10.2.1 dealing 
with RCU logon. 


DDU Manual Logon 

For DDU Manual Logon (i.e. when the OBFTP is not available), logon is controlled by the 
AFC application as illustrated in Figure 22. 

DDU configuration data includes a logon access file that includes a list of operator IDs, 
roles, and associated passwords. This file is downloaded to the DDU to authenticate 
manual logons when the OBFTP is unavailable. It is also part of OBFTP CD if manual 
logon is the configured logon method for that Agency. Therefore, even when the OBFTP 
is not available, the DDU manual logon flow will validate the operator ID with a password. 
Refer to the screen flows in Table 5 for the proposed screens and flow for manual logon 
using the DDU. 

The logic used for validating the operator ID, password and role is the same as defined 
for an OBFTP manual logon described in SEA-01050 Fare Transaction Processor - 
Functional Specification (DR 102 B) [10]. 

Iln the case where the FIM application requests an operator logon as described in section 

3.9.10.4.2 , the AFC application validates the information provided to it through the 
Shared Public Data and will accept such a request if all of the following conditions are 


1. FIM is enabled. 

2. The operator role bpecified bv the FIM application is valid. A rc commented [di6]: com-v15.o-oo6 

be the same as the default Driver role and, hence, is valid. 

3. The DDU is in Logon mode. 

4- 4. The driver has NOT advanced the DDU past the Enter Operator ID screen as this 

means he or she is attempting his or her own logon, which should not be interrupted. |_ ( commented [dl7]: Change Order #32 

Note: When the OBFTP is not available, the AFC application on the DDU still 
provides functions not related to fare collection. Essentially, only AFC 
functions to select run, route, or trip are available. Third-party application 
functions are not dependent on AFC and therefore are still available and 
unaffected. 


3.11.4.2.1.1 Manual Trip Detail Entry 

In the case of a DDU manual logon, fare collection (other than non-RFCS payments) is 
not possible. Trip details are still required to be entered by the operator to support third- 
party device applications. 

After a successful DDU manual logon, inj the AFC application prompts the operator 
to enter appropriate run/route/trip information. In FIM, this function is the responsibility of 

The DDU configuration data includes the trip data file as downloaded commented [di8]: change Order #32 
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to the OBFTP, and information entered by the operator is the same for the DDU manual 
logon as for the OBFTP-available manual logon. 

Refer to the screen flows in Table 5 for the proposed screens for DDU manual logon and 
trip selection. 


3.11.4.2.2 


OBFTP-Available Logon 

The screen flows and data entry screens are defined by the OBFTP and described in 
SEA-01050 Fare Transaction Processor - Functional Specification (DR 102 B) [10]. Refer 
also to the screen flows in Table 5 for the proposed screens and flow for manual or 
automatic logon performed by the OBFTP. 

Automatic logon is only possible using the OBFTP. If manual login is configured in CD as 
the logon method and the OBFTP is available, the logon is controlled by the OBFTP and 
not by the DDU as for the DDU manual logon in section 3.11.4.2.1. 

Iln the case where the FIM application requests an operator logon as described in section 

3.9.10.4.2 , the AFC application only passes the information provided to it through the 

Commented [dl9]: Change Order #32 

The AFC application waits for a response from the OBFTP indicating the logon result: 

• If the OBFTP returns valid logon details, the AFC application makes these details 
available to all third-party applications and the DDU enters On Trip mode. 

• If the OBFTP returns invalid logon details, the AFC application makes these details 
available to all third-party applications and returns to the start of Logon mode. 


3.11.5 On Trip Mode 

On Trip mode is configured by templates and managed by the Template Manager. The 
functionality available while on trip is dictated by the applications installed on the DDU. 
Regardless of the logon method, trip details are updated to the DDU public data area 
(refer to section 3.9.10.4). This enables all DDU applications access to trip details at any 
time. 

All OBFTP-related functionality is defined in SEA-01050 Fare Transaction Processor - 
Functional Specification (DR 102 B) [10]. 

Refer to the screen flows in Table 5 for the proposed screens while on trip, including fare 
collection screens, and those for third-party applications. 


3.11.6 End Trip Mode 

End Trip mode allows the operator to end the current trip by either starting a new trip or 
by ending the current shift. The end of the current trip is implied by initiation of either of 
these operations. 

Refer to the screen flows in Table 5 for the proposed screens for all trip management 
functions. 


Entry Conditions 

End Trip mode entry conditions are dependant on the logon method and the operational 
state of the OBFTP. 
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If the operator logged on to the device using either method of OBFTP-available logon, 
the OBFTP is operational, and a valid connection is present, the OBFTP-available 
End Trip sequence of events is followed. 

If the operator logged on to the device using either method of OBFTP-available logon 
and the OBFTP is no longer operational or a valid connection is no longer present, the 
Manual End Trip sequence of events is followed. 

If the operator logged on to the device using DDU Manual Logon, the DDU Manual 
End Trip sequence of events is followed. 


5 . 11 . 6.2 


DDU Manual End Trip - Sequence of Events 

1. From an on trip template on the DDU, the operator can choose from the following 
options: 

o Start New Trip 
o End Shift 

Note: The ‘Start New Trip' and ‘End Shift’ options above imply ending the 
current trip. 

2. Selecting the Start New Trip function will cause the operator to enter the Manual Trip 
Detail Entry Flow (OBFTP faulty or no communications) functionality as described in 
section 3.11.4.2.1.1. 

3. Selecting the End Shift function causes the AFC application to send logoff details to 
all applications and return to Logon mode. 

Iln FIM, both the Start New Trip and End Shift functions can also be triggered by the FIM 

application. 

In the case of the Start New Trip function, refer to section 3.9.10.4.4 for more details 
relating to Automatic Next Trip Selection. In this case, the AFC application validates the 

information provided to it through the Shared Public Data and will accept such a request 

if all of the following conditions are met. 

1. FIM is enabled. 


2. The DDU is in one of the main On-Trips screens, i.e. where the trip information is 

displayed or the Route/Run Entry screen. Navigation to a screen other than those 

mentioned above indicates the driver is actively attempting to view information or 

perform a task and should not be interrupted by such a request. 


3. The route/run/trip information provided by the FIM application can be used to identify 

a valid run and trip in the device’s CD. 

In the case of the End Shift function, refer to section 3.9.10.4.2 for more details relating to 
Operator Logout. In this case, the AFC application validates the information provided to it 

through the Shared Public Data and will accept such a request if all of the following 

conditions are met. 


1. FIM is enabled. 
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The DDU is in the Maintenance screen, the Supervisor screen, one of the main On- 

Trips screens, i.e. where the trip information is displayed or the Route/Run Entry 

screen. Navigation to a screen other than those mentioned above indicates the driver 

is actively attempting to view information or perform a task and should not be 

interrupted by such a request. In the case of the Route/Run Entry screen, such a 
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Commented [d20]: Change Order #32 


3.11.6.3 OBFTP-Available End Trip - Sequence of Events 

The operator is required to traverse the DDU templates to find the appropriate 
functionality required to perform the End Trip sequence as defined in SEA-01050 Fare 
Transaction Processor - Functional Specification (DR 102B) [10]. 

3.11.6.4 End Trip Mode - Exit Conditions 

The End Trip Mode exit conditions are: 

• [The operator u i_starts a newtrip (Manual End Trip sequence). 

• The operator ends theip-the shift (Manual End Trip sequence). Commented [d2l]: Change Order #32 

• The operator performs an OBFTP-available End Trip as defined in SEA-01050 Fare 
Transaction Processor - Functional Specification (DR 102B) [10]. 

3.11.7 Shutdown Mode 


Entry Conditions 

Shutdown mode is entered when the ignition input indicates that the vehicle is off and the 
device has been idle for greater than a CD-defined limit. 

Sequence of Events 

1. The application manager shuts down all applications. 

2. The application manager shuts down and shuts down the operating system. 

Exit Conditions 

Shutdown mode is exited when the device is powered off. 
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4 Quality Assurance (Duplicated in SEA-01047 

(DR 103 A)) 


4.1 General 

The DDU development includes the following stages of testing to ensure quality and 
compliance to requirements: 

• Article testing to verify that the DDU requirements are met 

• System testing to verify that the DDU operates in the target system 

• Field testing to verify over time that the DDU operates in the target environment 

4.2 Responsibility for Tests 

Testing is the responsibility of ERG, and it will be described in SEA-01199 Overall 
Inspection and Test Plan (CDRL 23) [8]. 

4.3 Application Certifications 

The Application Certification process, defined in section 3.6, is a key element of the 
quality program associated with the DDU, ensuring that third-party applications do not 
negatively impact the performance of the on-board architecture. 
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Appendix A Hardware Cross-Reference Matrix (Contained in SEA-01047 
(DR103A)) 

This appendix is intentionally left blank. 


To I 
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Appendix B Template Manager (DR 103.04) 

B.1 Template Definition Language 

An initialization file written in the template definition language (TDL) controls the 
Template Manager. The following section describes the TDL grammar in a BNF like 
notation. Note that “*” indicates 0 or more occurrences while “+” indicates 1 or more 
occurrences. Also note that a window with the same name may exist in more than one 
template, but no window may exist in any given template more than once. 



<template identified <title> 


"position(" <xpos> <ypos> 
"audio(" [ "0" | "1" ] ")" 


<window identified ::= cidentified 


<decal definition> ::= 




<decal identified 


SEA-01048 
Revision 16.0/22 


"image(" cimage path> ")" 
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The following example defines three templates, each containing three windows, as well 
as two decals. Comments are provided after the #. 
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# Top-level template (first to be displayed after Template Manager 

# is initialised. Used by Application Manager to display the Startup 

# screen in the 'AppMgrWindow'. 


# Application Manager takes control of this window and 

# in each template is, by default, the ACTIVE window. 

window(AppMgrWindow) 


position(40,72) 
size(240,128) 
audio(1) 


# The KCM radio application tak 

# and draws radio messages and 



templates 


position(40,0) 
size(240,44) 
audio(1) 


It The Status and Logging application takes c 
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# The AFC template used by the AFC to display its screens and/or the 

# OBFTPs screens in the 'AfcBase' window. 


# The AFC application takes control of this window and uses it 

# to display its logon and on-trip screens as well as the OBFTPs 



position(40,72) 
size(240,128) 
audio(1) 


# The KCM radio application tak 

# and draws radio messages and 



templates 


position(40,0) 
size(240,44) 
audio(1) 


# The Status and Logging applicatior 


position(40,44) 
size (240,28) 
audio(1) 
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B.2 Initialization and Template Definition Parser 

The Template Manager is a DLL, which is loaded by client applications. The primary 
client application (the Application Manager application) will call the Template Manager 
DLL’s initialization functions - TmLoadlconLib() and Tmlnitialise() passing to them the full 
path of the template images file and the template definition file, respectively. 

During initialization, the Template Manager opens and then parses the template definition 
file. If the software detects a syntax error, the parsing stops and a message indicating the 
nature and location of the error is displayed. No attempt is made to gracefully recover 
from errors because it is expected that the template definition is automatically generated 
by a separate tool and thus is normally correct. 

The template definition is transformed into a set of data structures which are defined in 
DPG-00393 DC5000 - Guidelines for Third Party Integrators [43], 

B.3 API Specification 

The Template Manager provides a set of API functions, which arbitrates any conflicts 
between Ul requirements of client applications. These APIs are described in detail in 
DPG-00393 DC5000 - Guidelines for Third Party Integrators [43], 
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Appendix C DDU Screen-Flow Presentations 


Table 5 outlines the suggested screen layouts and flows for the DDU. The screen flows 
reflect the agreed outcome of presentations and workshops with each Agency and, as 
applicable, regional agreement. 


Note: The screen-flow presentations included in Table 5 also include screens for 
the OBFTP as the two devices are closely related. While both DDU and 
OBFTP screens are depicted in the presentations, this document only 
covers those related to the DDU. Refer to SEA-01050 Fare Transaction 
Processor (DR 102B) - Functional Specification [7] for details of the 
OBFTP functionality. 

DDU/OBFTP LCD screen text, graphics, tones, LED indicators, and message text, as 
applicable, are all configurable via CD using CD configuration software. Different CD can 
be downloaded to different devices, allowing customization of the LCD screens for 
particular transit Agencies. Message sets and formats are to be approved by the Contract 
Administrator. 

Typical DDU/OBFTP screens are detailed in the PowerPoint presentations attached in 
Table 5. 

The presentations reflect the screen detail and sequencing between screens, however 
due to limitation of the presentation, some fonts shown may be an approximation of that 
achievable on the real devices. Similarly, the timing between screens has been set to 
facilitate viewing of the presentation; timing of screens on the DDU/OBFTP will be 
configurable in CD to suit driver and patron interactions as applicable. 
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Table 5: DDU Screen-Flow Presentations 


Embedded PowerPoint Presentation 

Description 

sq) m 

Typical DDU Screen Flows - KCM 

SEA-01314 KCM DDU SEA-01314 KCM DDU 
Operations Screenfb'Operations Screenfb' 

Hj) Hj 

Typical DDU Screen Flows - CT 

SEA-01305 CT DDU SEA-01305 CT DDU 
operations screen fb'operations screen fb' 

SO) SO) 

Typical DDU Screen Flows - PT 

SEA-01317 PT DDU SEA-01317 PT DDU 
Operations Screenflo'Operations Screenfb' 

ffi m ) 

Typical DDU Screen Flows - ET 

SEA-01469 ET DDU SEA-01469 ET DDU 
Operations Screen FkOperations Screen Fk 

m) ®) 

Typical DDU Screen Flows - KT 

SEA-01316 KT DDU SEA-01316 KT DDU 
Operations Screenflo'Operations Screenfb' 


Commented [jb22 ]: As Built updates to screenflows 
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C.1 Typical DDU Screen Flows - KCM 
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C.2 Typical DDU Screen Flows - CT 

Note: The toggle shown in screen 4.2 will cycle through all of the valid faresets 
for a particular trip. 
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C.3 Typical DDU Screen Flows - PT 
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C.4 Typical DDU Screen Flows - ET 
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C.5 Typical DDU Screen Flows - KT 
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Appendix D Traceability (Duplicated in SEA-01047 
(DR 103 A)) 

Table 6 traces the contractual requirements to ERG internal documentation. 

Table 6: Requirements Traceability to Contract [1] 

I Contract Reference DR Section Comment 
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Contract Reference 

DR Section 

Comment 

6.111-6.8.2(f) 

3.9.10.1.3 


6.111-6.8.3(a) 

3.9.10.2 


6.111-6.8.3(b) 

3.9.10.2 


6.111-6.8.3(0) 

3.9.10.2 


6.111-6.8.3(0(1) 

3.9.10.2 


6.lll-6.8.3(c)(ii) 

3.9.10.2 


6.111-6.8.3(0(111) 

3.9.10.2 


6,lll-6.8.3(c)(iv) 

3.9.10.2 


6.lll-6.8.3(c)(v) 

3.9.10.2 


6.lll-6.8.3(e)(vi) 

3.9.10.2 


6.l(l-6.8.3(c)(vii) 

3.9.10.2 


6.l(l-6.8.3(c)viii) 

3.9.10.2 


6.111-6.8.3(0 

3.9.10.2 


6.111-6.8.3(e) 

2.2 

See SEA-01047 Driver Display Unit (DR 

6.111-6.8.3(f) 

2.2 

See SEA-01047 Driver Display Unit (DR 

6.111-6.8.4 

3.9.10.1 

SEA-00542 RFCSRFI 0022 - CT DDU 
Integration [13], 

6.111-6.8.4(a) 

3.9.10.1 


6.111-6.8.4(3)0) 

3.9.10.1 


6.lll-6.8.4(a)(ii) 

3.9.10.1 


6.lll-6.8.4(a)(iii) 

3.9.10.1 


6.111-6.8.4(0 

3.9.10.1.2.2 


6.111-6.8.4(0 

3.9.10.1.1 


6.111-6.8.4(0 

3.9.10.1.2.3 


6.111-6.8.4(e) 

3.11.3 


6.111-6.8.4(f) 

3.9.10.1.2.5 


6.lll-6.8.4(g) 

3.9.10.1.2.5 


6.111-6.8.4(0 

3.9.10.1.2.5 


6.III-6.8.5.1 



6.111-6.8.5.2 

3.9.7 


6.111-6.8.5.3(a) 

3.9.8 


6.111-6.8.5.3(0 

3.9.8 


6.111-6.8.5.3(0 

3.9.8 



3.9.10.2 

















































on iac e eience 

ec ion 

ommen 

6.ill-6.8.5.4(b) 

3.9.10.2 


6.lll-6.8.5.4(c) 

3.9.10.2 


6.111-6.8.5.5(3) 

3.9.10.2 


6.lll-6.8.5.5(b) 

3.9.10.4^3,9.10.4.1 


6.111-6.8.5.5(0 

3.9.10.4^3.9.10.4.1 


6,Hll-6.8.5,5(d) 

3.9.10.4 J3.9.10.4.2, 
3.11.4.1 


6.ill-6.8.5.5(e) 

3.9.10.4^0^3.11.4.2.1.1 


6.111-6.8.5.5(1) 

3.9.10.4^0 


6.111-6.8.5.5(0) 

3.9.10.4^3.11.6.2 


6.lll-6.8.5.5(h) 

3.9.10.4^3.9.10.4.5 


6.ill-6.8.5.6(a) 

3.9.10.4J.9.10.4.2, 

3.11-4.1j_3.il.8.2 


6.111-6.8.5.6(0 

3.9.10.4^3.9.10.4.2^ 

3.11-4.1j_3.il.6.2 


6.111-6.8.5.6(0 

3.9.10.4^3.9.10.4.2^ 

3.11.4.1j_3.11.4.2.1. 
3.11.4.2.2 


6.lll-6.8.5.6(d) 

3.9.10.4^3.9.10.4.2^ 

3.11-4.1j 3.il.8.2 


6.111-6.8.5.7 

3.10 


6.lll-6.8.5Z(a) 

3.6 


6.IM-6.8.§Z(a)(i) 

3.6 


6.lll-6.8.§Z(a)(ii) 

3.6 


6.lll-6.8.SZ(b) 

3.6 


6.lll-6.8.SZ(b)(i) 

3.6 


6.lll-6.8.§Z(b)(ii) 

3.6 


6.III-6.8.5Z(C) 

3.6 


6.lll-6.8.§Z(c)(i) 

3.6 


6.lll-6.8.§Z(c)(ii) 

3.6 


6.lll-6.8.5Z(c)(iii) 

3.6 


6.lll-6.8.§Z(cl) 

3.6 



Table 7 shows traceability between the non-Contract changes (CCA#3) RFIs / 
Requirements, Change Orders (COs), and Change Requests (CRs)), and this document. 
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Table 7: Non-Contract Traceability Matrix 


RFI/REQ Reference 

DR Section 

Comment 

RFCS RFI 236, EQP-003 

3.8.1,3.9.3, 3.9.4,3.9.9.1, All 
sections of all screenflows 

DDU Display - Clock visibility 

RFCS RFI 236. EQP-012 

3.11.2 

Manaaina Data Transfer 

RFCS RFI 236, EQP-051 

3.9.4.1 

Error logging 

RFCS RFI 237, EQP-013 

Topic 3 in KCM screenflow 

KCM DDU - RTT key 

RFCS RFI 237, EQP-042 

Topic 2 in PT screenflow 

PT DDU - Pass icon 

RFCS RFI 237, EQP-043 

Topic 2 in PT screenflow 

PT DDU - Promotional and Bicycle icons 

RFCS RFI 237, EQP-044 

Topic 2 in PT screenflow 

PT DDU - Short Fare icon 

RFCS RFI 237, EQP-045 

Topic 4.4 in PT screenflow 

PT DDU - Multiple Fare Counter 

RFCS RFI 237, EQP-049 

Topics 2, 4.1,4.3 and 5 in PT 
screenflow 

PT DDU - ST icons 

RFCS RFI 238, EQP-025 

Topic 15 in KCM screenflow 

KCM DDU Volume Controls 

RFCS RFI 336, EQP-024 

Topic 18 in KCM screenflow, 
Topic 9 in CT screenflow, 

Topic 8 in KT screenflow, 

Topic 9 in PT screenflow, 

Topic 8 in ET screenflow 

DDU Messages - Revise messages 

RFCS RFI 336, EQP-030 

Topic 18 in KCM screenflow, 
Topic 9 in CT screenflow, 

Topic 8 in KT screenflow, 

Topic 9 in PT screenflow, 

Topic 8 in ET screenflow 

FTP Messages - Revise messages 

RFCS RFI 264, CDA-001 

Topic 48 in KCM screenflow, 
Topic 36 in CT screenflow, 
Topic 34 in KT screenflow, 
Topic 35 in PT screenflow, 
Topic 34 in ET screenflow 

DDU/OBFTP verification tool for the regional test bed 

RFCS RFI 266, CDA-004 

Topic 48 in KCM screenflow, 
Topic 36 in CT screenflow, 
Topic 34 in KT screenflow, 
Topic 35 in PT screenflow, 
Topic 34 in ET screenflow 

Testing specific dates in the RTB 

Change Order 32 

3.9.10.3,3.9.10.4,3.9.10.4.1, 

3.9.10.4.2J3.9.10.4.3, 

3.11.3.2JT11.4.1J3A4.2.1* 
3.11.4.2.1.1J3.11.4.2.2, 
3.11.6.2J3.11.6.4L 
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